In a cloud computing environment, an infrastructure including server computers and other computing hardware can be shared among multiple different customers or tenants. The infrastructure may be provided as a service, e.g., Infrastructure As A Service (IAAS). Infrastructure can also include operating system and software elements that are essential to the operation of the hardware, and/or that all customers are likely to use. Each such customer or a tenant can lease some share of the infrastructure. In this manner, customers can obtain computational resources for performing their computing tasks without heavily investing in equipment—that is, infrastructure—to perform those tasks.
Infrastructure can be used by the customers as a service, but not owned by the customers. The customers typically purchase a time-based or resource quota-based share of the use of the infrastructure from the owner of the infrastructure. The owner then provides the infrastructure resources to the customers, so that the customers can use as the resources as they desire. The specific identities and locations of resources for an infrastructure on which the customer's tasks execute might not even be apparent to the customers; such details need not concern them. The cloud therefore abstracts the infrastructure to the customers as a service (e.g., IAAS).
More generally, cloud computing involves the use of computing resources (e.g., hardware and software) that are delivered as a service over a network (typically the Internet). Cloud computing entrusts remote services with a user's data, software, and computation. Cloud computing can also be used to offer software as service (Saas) or a platform as a service (PaaS), for example. In a business model using SaaS, users can be provided access to application software and databases. The cloud providers can manage the infrastructure and platforms on which the applications execute. SaaS providers generally price applications using a subscription fee. SaaS can allow a business the potential to reduce information technology operational costs by outsourcing hardware and software maintenance and support to the cloud provider. This outsourcing can enable the business to reallocate information technology operations costs away from hardware/software spending and personnel expenses, towards meeting other information technology goals. Furthermore, with applications hosted centrally, updates can be released without the need for users to install new software. However, because users' data are stored on the cloud provider's server, some organizations can be concerned about potential unauthorized access to that data.
End users can access cloud-based applications through a web browser or a light-weight desktop or mobile application. Meanwhile, the business software and users' data can be stored on servers at a location that is remote from that business and from those users. Cloud computing at least theoretically allows enterprises to deploy their applications more rapidly, with improved manageability and less maintenance. Cloud computing at least theoretically enables information technology managers to adjust resources more quickly to meet sometimes fluctuating and unpredictable business demands.
Because each customer or tenant of a cloud computing environment is likely to be associated with multiple separate users, each having a separate user identity, the infrastructure provided by a cloud computing environment can include an identity management (IDM) element. IDM involves controlling information about users of computer system. Such information can include information that authenticates the identities of such users. Such information can include information that describes which data those users are authorized to access. Such information can include information that describes which actions those users are authorized to perform relative to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.) IDM can also include the management of descriptive information about each user and about how and by whom that descriptive information can be accessed and modified.
Potentially, a cloud computing environment could include a separate IDM system, or separate instance of an IDM system, for each separate organization that used the cloud computing environment. However, such a scheme could be seen as being duplicative of effort and as being wasteful of computing resources. Therefore, instead of spawning a separate IDM system for each cloud tenant, a single cloud-wide shared IDM system can be implemented to serve all of the cloud's tenants. The IDM can be partitioned into multiple separate identity domains-one or more per tenant.
Within the cloud computing environment, a set of constructs can be created which, when all aligned together, expose an abstraction of, or “tenant-sliced” view of, a single IDM system. This single IDM system can include multiple separate components or sub-systems. The IDM system can be shared among multiple independent and separate tenants, or IDM system customers, so that the IDM system is more densely utilized. Thus, there is no need for a separate IDM system to be instantiated for each separate customer. The single IDM system can be configured such that, for each tenant of the IDM system, a virtual view of the IDM system that is specific to that tenant can be presented to that tenant's users.
Separate views of the IDM system can be virtualized within the single IDM system in a manner that is conceptually similar to the manner in which multiple separate virtual machines can be virtualized on a single host computing device. This virtualization can be achieved by configuring the IDM system in a specific manner. The IDM system can involve multiple separate layers, including upper layers and lower layers that are conceptually vertically stacked one on top of the other. The upper layers, at least, can be partitioned. In the IDM system, various different services (e.g., authentication and/or authorization services) can be associated with various different tenants of the IDM system. The IDM system can isolate each tenant so that each tenant is capable of interacting only with the IDM system “slice,” or partition, that is dedicated to that tenant. Thus, the IDM system can enforce isolation between tenants.
For each separate tenant, the shared IDM system can store the identities of the users that are associated with that tenant. Additionally, for each separate tenant, the shared IDM system can store definitions of rules that are associated with that tenant. Within the data structures maintained by the shared IDM system, each tenant can be represented as a top-level container. Because the shared IDM system enforces isolation between these containers, a user associated with a first tenant is prevented from accessing information about a user associated with a second, different tenant.
Various different infrastructure components can be provided within a cloud computing environment. One such component is a system that provides a multi-tenant virtualized environment (e.g., a Nimbula System). Within the environment, each separate tenant can be associated with a separate isolated hierarchy of resources that are accessible only to that tenant. Each tenant's hierarchy can include resources such as virtual machines, storage volumes (e.g., virtual hard drives) that can be accessed by those virtual machines, and other entities that represent and manage the tenant's objects. A Nimbula system can prevent users and applications in one tenant's hierarchy from accessing any other tenant's hierarchy.
Although a shared IDM system and a Nimbula system both provide cloud computing resources to customers in a shared manner, these systems sometimes do not represent things in the same manner. For example, a shared IDM system might be compared to an orchard, in which each tenant or customer of the system is represented as a completely separate tree. In contrast, a Nimbula system might be compared to a single tree trunk having many branches diverging from it, in which each branch emerging directly from the trunk corresponds to a separate tenant or customer of the system. Even if a shared IDM system involves some over-arching structure that contains all of the many different customers' hierarchies, the shared IDM system does not represent the hierarchies as being any part of such an over-arching structure in any way. The customers of the shared IDM system do not view their hierarchies as being part of such an over-arching structure. In contrast, a common root from which all customers' hierarchies descend exists in a Nimbula system, and this common root is visible to the customers of the Nimbula system, even if the common root is not accessible to those customers.
The different ways in which these systems represent tenants' hierarchies can make the integration or interfacing of these systems difficult. The differences in representation also can make migration directly from one kind of system to the other a complicated matter.